More details of browser behaviour in this respect can be found
in some associated documents.
The HTML2.0 spec only considers the situation where
NAME=nnn
has been specified (and no
VALUE
attribute), but there is no definite specification
of what a text-mode browser should do.
Some known combinations are tabulated below: c,d represent
decimal values of x, y co-ordinates in pixels, nnn and vvv are
character strings, & is the standard forms-submission separator
and (although not shown) form contents are sent encoded in the
way that is specified by the standard.
(Browsers are
somewhat erratic as to whether they send a space as "+" or "%20",
but that is not discussed here as it will normally be
resolved by whatever forms-analysis library you are using.)
WinMosaic 2.1, when the NAME attribute was omitted, bizarrely used the NAME that had been specified on the earlier TYPE=IMAGE item!
Form submission by INPUT TYPE=IMAGE with various combinations of NAME and
VALUE | ||||
---|---|---|---|---|
Browser | Neither | NAME=nnn [*] | VALUE=vvv | Both |
Netscape2.0 | x=c&y=d | nnn.x=c&nnn.y=d | vvv ignored | |
WinMosaic2.1 | See text! | nnn.x=c&nnn.y=d | vvv ignored | |
Lynx2-4 & FM | (none) | nnn.x=0&nnn.y=0 | (none) | nnn=vvv |
emacs-w3 | .x=0&.y=0 | nnn.x=0&nnn.y=0 | vvv ignored |
The column marked [*] is the situation specified in the HTML2.0 standard
The most consistent behaviour can be seen to be the one specified in the standard (not suprisingly). Provided due consideration is given to the fact that text-mode users only send co-ordinate values 0,0, all browsers give equivalent results.
In the situation where the IMAGE is used merely as a decorative SUBMIT button, provided the form analysis software is programmed to disregard the various forms of the x,y response, all should be well even if the NAME is omitted, but then it's not possible to determine which of several buttons was pressed. The presence of a VALUE attribute affects what Lynx displays (but not emacs-w3), as well as affecting what Lynx sends (but not emacs-w3).
From Foteos Macrides' mail to me, I have the distinct impression that he had intended that authors might supply a VALUE attribute, and detect the difference between Lynx and other browsers by testing the result: this would seem to me a commendable way of dealing with text-mode browsers, if it was documented and obeyed by them all. As it is, authors can provide a VALUE attribute, if they wish to get it displayed by Lynx; but this has no effect on emacs-w3 (neither in respect of its display nor in respect of what it sends), and if they wish to deal with all possible browser responses, they'll then have to be prepared for Lynx's nnn=vvv response as well as emacs-w3's nnn.x=0&nnn.y=0 response.
The contents of this article were originally published at http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/type-image.html, where they are currently maintained.
Original materials © Copyright 1994, 1995, 1996 A.J.Flavell & Glasgow University
Home, Questions, Members, WDG Award, Reference, Design, Links